Содержание
1 Исследование предметной области 4
1.1 Анализ проектной деятельности в РФ 4
1.2 Исследование типовых рисков ИТ-проекта 6
1.3 Анализ фармацевтической отрасли 7
1.3.1 Информатизация фармацевтической отрасли 7
1.3.2 Система обеспечения и контроля качества 10
1.4 Исследование методологии ASAP 14
1.4.1 Общее описание методологии 14
1.4.2 Сильные и слабые стороны методологии 23
1.4.3 Использование методологии 25
Выводы по 1 главе 30
Список использованных источников 31

1 Исследование предметной области

1.1 Анализ проектной деятельности в РФ

Рассматривая методологию ASAP можно определенно сказать, что методология внедрения корпоративной информационной системы — это гарантия качества, это основное средство для решения любой проблемы. Проблемы, с которыми приходится сталкиваться на проектах, начинаются от взаимодействия проектной команды и заказчика и заканчиваются при эксплуатации системы пользователями. Для того, чтобы лучше понять, с какими проблемами приходится сталкиваться, применяя методологию внедрения на российских проектах, рассмотрим данное применение более подробно.
Необходимо сразу отметить, что, в отличие от развитых стран, российский заказчик обладает более низким уровнем развития, и для постановки хорошего сервиса и грамотного построения процессов необходимо еще многое пройти. На рисунке 1 представлена схема распределения российских предприятий по уровню развития.
Рисунок 1 — Распределение предприятий по уровню развития
Необходимо сделать уточнение, как определяется уровень развития предприятия. Уровень развития предприятий определяется технологиями, используемыми предприятием, в том числе и технологиями управления. Уровень развития предлагается оценивать по шкале от 0-го уровня до 4-го для российских предприятий (до 6-го для передовых предприятий промышленно развитых стран) [1].
Из графика четко видно, что большинство российских предприятий не дотягивает до соответствующего уровня развития промышленно-развитых стран, и эта ситуация наблюдается не только в части технологической, но и управленческой. Поэтому, для российских проектов было бы очень полезно при внедрении системы строго соблюдать все пункты, описанные в методологии внедрения. Но, к сожалению, это не всегда получается, а как показывает статистика, для российских проектов это случается крайне редко.
В связи с низким уровнем развития предприятий, на начальной фазе проекта уже возникают проблемы с определением и постановкой бизнес-целей у заказчика. Вопросу постановке целей в методологии ASAP удаляется не так много информации, сколько бы пригодилось для решения существующей проблемы.
Неумение определить бизнес-цель вызывает необходимость у консультантов проводить более подробный анализ бизнес-процессов с целью помочь заказчику выяснить и определить его цели. При этом возникают задержки проекта, и непонимания со стороны заказчика вызовут низкий уровень управления проектом, а как итог — будут более высокие риски.
На проектах внедрения со стороны заказчика, обязательно выделяют ключевых пользователей – это люди, которым выпали полномочия представлять интересы заказчика на проекте. Наилучшее количество таких людей составляет 5-8 человек на проекте, однако это встречается крайне редко. При таком количестве инициативных пользователей выяснение требований и построению существующего бизнес-процесса будет проходить в нужном темпе, и существует большая вероятностью выполнения проекта в срок. Одна из основных задач ключевых пользователей быть хорошо знакомыми с процессами, которые предстоит автоматизировать и при возможности суметь эти процессы измерить.
Помимо того, что заказчик чаще всего бывает не в состоянии определить цели проекта, еще существует тенденция того, что он не осознает и не понимает той нагрузки и количества работ, которые необходимо будет проделать в течение проекта. Если заказчик с большой неохотой участвует в интервью, промежуточных тестах, подготовки данных для загрузки, то что говорить о приемке результатов, хотя этот процесс напрямую зависит от заказчика и подразумевает очень трудоемкие работы. В большинстве случаев проблема несоблюдения сроков связана с тем, что заказчик не успевает принимать работы, которую выполняют консультанты.
С целью помочь как можно эффективнее и быстрее на начальном этапе наладить взаимодействие и существует методология ASAP, в которой описаны основные шаги, которые необходимо предпринять.

1.2 Исследование типовых рисков ИТ-проекта

На сегодняшний день не существует ни одного ИТ-проекта, который был бы полностью лишен рисков. С различными проектами может быть связано разное число рисков, но проектов без рисков больших или малых не бывает. В ИТ-проектах всегда существуют неопределенности, связанные как с предметом проекта, так и с внешними условиями, оказывающими влияние на успешное достижение запланированного результата. Поскольку невозможно полностью избежать рисков, то следует искать разумные компромиссы между рисками и потенциальными возможностями, не следует стремиться к минимизации риска ценой исключения всего остального.
Основной причиной возникновения рисков являются неопределенности, которые существуют в каждом проекте. Риски могут быть неизвестные — те, которые не идентифицированы и не могут быть спрогнозированы. Риски могут быть известные — те, которые определены, оценены, для которых возможно планирование. Хотя специфические риски и условия их возникновения не определены, менеджеры проекта знают, исходя из прошлого опыта, что большую часть рисков можно предвидеть. Реализуя проекты, имеющие высокую степень неопределенности в таких элементах, как цели и технологии их достижения, многие компании уделяют внимание разработке и применению корпоративных методов управления рисками [2].
Основные риски, как правило, характерны для любых проектов и заключаются в несоблюдении сроков реализации проекта, превышения стоимости и несоблюдения параметров качества. Однако основной причиной возникновения этих рисков, особенно в ИТ-проектах, является неготовность предприятия к реализации подобных проектов. Перечислим несколько типичных причин этого явления:
̶ неготовность топ-менеджмента к изменениям в бизнес-процессах предприятия и организационной структуры;
̶ незаинтересованность руководителей основных подразделений;
̶ смена в ходе реализации проекта менеджера проекта;
̶ недостаточная квалификация менеджера проекта и ответственных исполнителей.
Основные риски реализации ИТ-проекта на предприятии можно сформулировать таким образом:
̶ отсутствие системного аналитика для постановки задачи управления на предприятии;
̶ сопротивление сотрудников;
̶ увеличение нагрузки во время реализации проекта;
̶ отсутствие лидера и квалифицированной команды;
̶ изменение целей в ходе реализации проекта.
Смысл описания рисков реализации ИТ-проектов заключается в том, чтобы заранее выявить эти риски и провести комплекс предупреждающих мероприятий, а не получить трудноразрешимые проблемы во время реализации проекта. В качестве основных мероприятий, направленных на избежание возникновения этих рисковых ситуаций в ИТ-проектах, являются:
̶ обязательное документирование целей проекта, а также всех изменений в документации проекта, возникающих при его реализации;
̶ повышение мотивации рядовых сотрудников путем материального стимулирования;
̶ привлечение сторонних квалифицированных специалистов;
̶ обучение членов команды и топ-менеджмента методологии управления проектами.
Можно сделать вывод о том, что ключевые рисковые факторы, которые имеют высокую весомость в проекте, недостаточно соблюдаются только лишь при использовании стандартной методологии ASAP. Это означает, что для успешной реализации проекта, необходимо будет обращаться к адаптированной под требования фармацевтической отрасли методологии ASAP.
1.3 Анализ фармацевтической отрасли
1.3.1 Информатизация фармацевтической отрасли
Использование новых технологий в фармацевтическом секторе позволит компаниям снизить затраты на разработку лекарств на 75%, сократить сроки разработки на 9 лет [3].
Подразделение IBM Business Consulting Services (BCS) выпустило отчет о новом исследовании, посвященном фармацевтической отрасли. В отчете названы семь ключевых информационных технологий, которые станут двигателем прогресса фармацевтической отрасли и повысят ее привлекательность для акционеров в предстоящее десятилетие. IBM прогнозирует, что эти семь технологий помогут фармацевтической отрасли:
̶ снизить затраты на разработку лекарственного препарата до начала серийного производства до уровня $200 млн. (1/4 часть текущих затрат в расчете на один препарат);
̶ сократить средние сроки разработки с 12–14 лет до 3–5 лет;
̶ повысить качество процессов разработки и производства;
̶ вывести на новый уровень экономическую отдачу для акционеров компаний.
Сегодня компании фармацевтической отрасли тратят на информационные технологии около $20 млрд. в год, однако редко получают от этих инвестиций полноценную отдачу. Большинство ИТ-ресурсов компаний направляется на технологии, предназначенные для сокращения затрат – управление цепочкой поставок, обработку транзакций, услуги поддержки – и все больше таких технологий передается для поддержки внешним поставщикам.
Отрасль уже переживает важнейшие изменения, связанные с появлением молекулярных подходов. Генетика, геномика, протеомика в будущем позволят фармацевтическим компаниям точнее идентифицировать заболевания и создавать целые пакеты решений по защите здоровья для пациентов с конкретными подтипами заболеваний, вместо того, чтобы производить «безразмерные» лекарства для пациентов со схожими симптомами, но разными, по сути, болезнями. Компании, которые научатся создавать целенаправленные терапевтические решения, к 2010 году смогут в разы увеличить прибыль своих акционеров. Ключом к такой трансформации станут информационные технологии.
Жизненно важным фактором этого преобразования и повышения инвестиционной привлекательности фармацевтических компаний в ближайшее десятилетие станут семь ключевых технологий:
а) высокопроизводительные системы;
Вскоре появится новое поколение компьютеров с производительностью на уровне петафлоп, которые создадут условия для массового применения биомолекулярного моделирования, например, конформационного анализа белков.
б) Grid-технологии;
Grid-технологии, позволяющие эффективно использовать простаивающие вычислительные ресурсы, предоставят компаниям возможность браться за такие задачи, как скрининг на совпадение ДНК-последовательностей или анализ данных о продажах и маркетинге в реальном времени. Ряд исследовательских Grid-систем уже действует. В качестве примера можно привести проект Smallpox Research Grid, в рамках которого на двух миллионах компьютерах добровольцев по всему миру был проведен скрининг 35 млн. потенциальных лекарств для лечения ветряной оспы.
в) прогностическое биомоделирование;
Появится возможность использования сложных компьютерных моделей для исследования функционирования биологических систем как целого. Благодаря прогностическому биомоделированию, фармацевтические компании получают возможность существенно сократить количество лабораторных экспериментов, затрачиваемых на выявление потенциальных лекарственных средств. Такое моделирование также позволяет исследователям прогнозировать влияние лекарств на организм человека, в том числе оценивая их эффективность и безопасность. Построением компьютерных моделей реагирования клеток на химические воздействия занимается целый ряд исследовательских организаций.
г) интеллектуальные маркеры и радиочастотные идентификаторы;
Появится возможность идентификации продукции на любых этапах производства и дистрибуции. Радиометки будут играть ключевую роль в замене традиционно медленных и неэффективных производственных процессов и переходе фармацевтических компаний на новые методы работы и выпуск более широкого ассортимента более сложных лекарственных средств более мелкими партиями. Они также помогут компаниям удовлетворить все более жестким нормативным и законодательным требованиям, позволив контролировать движения фармацевтической продукции во всех звеньях цепочки поставок, и откроют новые возможности для оказания услуг здравоохранения.
д) усовершенствованные решения для хранения данных;
Появится возможность предоставления средства для организации хранения огромных объемов данных, которые создаются сегодня в отрасли, и управления ими. Новые мощные серверы хранения данных, виртуализованные распределенные сети хранения и прозрачные интегрированные системы управления записями и архивирования помогут отрасли выполнять все более жесткие требования американского Управления по надзору за качеством пищевых продуктов и медикаментов (FDA), комиссии по ценным бумагам и биржам и других регулирующих организаций.
е) технологии анализа производственных процессов.
Появится возможность автоматически контролировать процессы производства в реальном времени вместо того, чтобы делать это постфактум, на основании контрольных образцов и данных выходного контроля качества. Технология повышает качество производства и экономят средства, поскольку дешевле провести текущую коррекцию параметров производственного процесса, чем браковать продукцию, вышедшую за рамки допустимых отклонений.
1.3.2 Система обеспечения и контроля качества
GxP (Good … Practice, Надлежащая … практика) — признанная во всем мире система обеспечения качества лекарственных средств. Система GxP охватывает все этапы жизненного цикла лекарственного средства — от фармацевтической разработки до конечного потребителя, а именно [4]:
̶ доклинические (лабораторные) исследования, которые регулируются правилами GLP (Good Laboratory Practice, Надлежащая лабораторная практика);
̶ клинические испытания, которые регулируются правилами GCP
(Good Clinical Practice, Надлежащая клиническая практика);
̶ производство, которое регулируется правилами GMP
(Good Manufacturing Practice, Надлежащая производственная практика);
̶ хранение, которое регулируется правилами GSP
(Good Service Practice, Надлежащая практика хранения);
̶ оптовая торговля, которая регулируется правилами GDP
(Good Distribution Practice, Надлежащая практика оптовой продажи);
̶ розничная торговля, которая регулируется правилами GPP
(Good Participatory Practice, Надлежащая практика розничной продажи).
Рисунок 2 — Система GxP
Лекарственные средства как продукт фармацевтической деятельности существенным образом отличается от всех других видов продукции. В основе этого отличия лежат специфические особенности, присущие только данному виду продукции, а именно:
̶ эффективность терапевтического действия достигается только при строго определенной дозировке одного или нескольких лекарственных веществ, входящих в состав лекарственного средства;
̶ все составные части лекарственного средства (действующие и вспомогательные вещества) строго нормируются спецификациями по качеству и количеству;
̶ каждая единица продукции (таблетки, капсулы, драже, флакон, ампула и т.д.) в серии должна строго соответствовать требованиям спецификаций не зависимо от количества единиц продукции в данной серии;
̶ каждая единица продукции в серии должна сохранять свои терапевтические свойства на протяжении всего срока хранения, указанного в тех же спецификациях;
̶ все серии фармацевтической продукции данного конкретного наименования должны всегда и везде соответствовать требованиямспецификации.
GxP требует от процессов четкой определенности, повторяемости и контролируемости. Все критические процессы должны проходить валидацию, чтобы гарантировать стабильность и соответствие спецификациям. Кроме этого системы требует выполнение ниже следующих постулатов [5]:
а) лекарственные средства разработаны с учетом всех требований стандарта GxP и требований к работе лабораторий;
б) на все производственные и контрольные операции существует четкая документация, разработанная в соответствии с GxP;
в) ответственность и обязанности всех работников четко определены;
г) работники организации должны проходить периодическое обучение выполнения процедур;
д) предусматриваются меры, обеспечивающие производство, поставку и использование исходных и упаковочных материалов, которые удовлетворяют заданным требованиям;
е) контроль промежуточной продукции и технологического процесса (внутрипроизводственный контроль) и валидация процессов и оборудования проводятся в необходимом объеме;
ж) производство и контроль готовой продукции выполняются в соответствии с утвержденными инструкциями (методиками);
з) исключается реализация лекарственных средств до выдачи ответственным (уполномоченным) лицом разрешения на выпуск, которое подтверждает, что каждая серия продукции произведена и проверена в соответствии с установленными требованиями;
и) существование системы мер, обеспечивающей, насколько это возможно, поддержание уровня качества лекарственных средств при их хранении, отгрузке и последующем обращении в течение всего срока годности;
к) существование порядка проведения самоинспекции и/или аудита качества, на основании которого регулярно оценивается эффективность системы обеспечения качества;
л) немедленная реакция и расследование рекламаций, установление причин, выполнение корректирующих и предупредительных действий для предотвращения повторения проблемы.
Система GxP позволяет эффективно организовать процессы и обеспечить конкурентоспособность готовых лекарственных средств, сделать предприятие привлекательным для государственных и частных инвестиций, а также для налаживания партнерских отношений не только на внутреннем, но и на зарубежном рынках. Ее требования являются гибкими, и позволяют учитывать местные условия и особенности конкретного предприятия. Принципиально важно осознать, что требования GxP предъявляются не только к оборудованию и помещениям, но и к персоналу, принципам и подходам в управлении предприятием.
Особое место GxP отводит руководству компании, давая тем самым понять, что неверно рассматривать качество лекарственного препарата без взаимосвязи с системой управления в компании. Если нет ожидаемого качества препарата, то даже эффективный менеджмент не приведет компанию к успеху, и наоборот, если в компании отсутствует команда, способная выстроить эффективную систему управления таким образом, чтобы производить препарат надлежащего качества, тогда это вдвойне критично. Участие высшего руководства, его пример и мотивация как раз позволяют построить систему качества не на страх, а на совесть. Система качества эффективна только там, где руководство реально возглавляет процесс ее создания и развития. В частности, со стороны руководства необходимо проведение анализа и оценки пригодности и эффективности системы качества, с целью выявления принятия решений об изменениях и улучшениях. Иными словами, анализ следует организовать таким образом, чтобы представителям высшего руководства было удобно его проводить, и чтобы все они в полной мере в нем участвовали [6].
Определенные функции по анализу следует делегировать на разные уровни управления в компании. Без вовлечения всего управленческого персонала система работать не будет. Другой вопрос, что часто полномочия линейных руководителей подменяются функциями ответственного, отчитывающегося за результат деятельности по заданным критериям. Как правило, такие критерии навязаны и, чаще всего, не подкреплены ресурсами для реализации принимаемых решений.
В ходе анализа со стороны руководства необходимо оценивать:
̶ результаты самоинспекций, внешних надзорных аудитов, и аудитов клиентов;
̶ результаты измерения удовлетворенности потребителя, включая жалобы и рекламации;
̶ результаты мониторинга процессов и качества продукции;
̶ выполнение запланированных действий;
̶ соответствие политике компании в сфере качества и степень достижения целей по качеству;
̶ влияние предполагаемых изменений и т.п.
Результатом анализа со стороны руководства, как правило, являются решения в виде приказов, распоряжений и планов по улучшению процессов, продукции, распространению необходимых знаний и оптимизации ресурсов.
GxP требует проведения мониторинга процессов и качества продукции. Мониторинг – это необходимость проведения всех проверок, испытаний и верификации, а также контроль доступности всей необходимой документации. Целью является возможность продемонстрировать выполнение заданных требований. Мониторинг качества продукта подразумевает проведение постоянного контроля на соответствующих этапах процесса производства, контроля, хранения и отпуска для подтверждения соответствия всем установленным требованиям. При этом, чем меньше доверия вызывают результаты прямого контроля продукции, тем более надежным должен быть мониторинг процессов, влияющих на качество такой продукции.
Инновации, постоянное совершенствование, данные мониторинга процессов и качества продукта, а также корректирующие и предупреждающие действия всегда ведут к изменениям. GxP вводит понятие системы управления изменениями, которая позволит проводить необходимую оценку, одобрение и внедрение изменений. Такая система обеспечит своевременность и эффективность непрерывного совершенствования, и, в то же время, даст высокую степень уверенности в отсутствии незапланированных последствий любых изменений.
1.4 Исследование методологии ASAP
1.4.1 Общее описание методологии
Методология AcceleratedSAP (ASAP) представляет собой маршрутную карту, представляющую проект внедрения в виде пути через пять основных фаз и семь рабочих потоков [7]:
Рисунок 3 — Маршрутная карта ASAP
Маршрутная карта ASAP была разработана для поддержки усилий проектных команд, направленных на планирование, управление и завершение проектов на всем протяжении внедрения и эксплуатации решений SAP.
Маршрутная карта внедрения состоит из пяти фаз:
̶ начальная подготовка;
̶ концептуальный проект;
̶ реализация;
̶ заключительная подготовка;
̶ эксплуатация и поддержка.
Каждая фаза, как показано на рисунке 3, визуализируется в разрезе областей знаний проекта внедрения. В рамках каждой отдельной области знаний выполняются группы работ, состоящие из отдельных работ, которые порождают на выходе результат, который чаще всего представляет собой какой-либо рабочий документ или документы, называемые в терминологии ASAP акселераторами. Именно ориентированность методологии ASAP на создание большого количества документации и дала ей название «AcceleratedSAP».
В основу методологии ASAP заложена строгая каскадная модель. Каждая фаза включает формальную процедуру запуска и формальную фазу завершения, включающую набор строгих контрольных мероприятий.
Кратко рассмотрим каждую из пяти фаз, используя материалы самой дорожной карты:
а) подготовка проекта;
Назначение фазы начальной подготовки — это поддержка предварительного планирования и приготовлений для нового SAP проекта. Несмотря на то, что каждый SAP проект имеет собственные уникальные цели, границы и приоритеты, шаги данной фазы помогают идентифицировать и планировать ключевые вопросы бизнеса, которые нуждаются в согласовании.
В начале проекта необходимо обратиться к некоторым важным вещам:
̶ определение целей проекта, ориентированных на корпоративные стратегические цели;
̶ прояснения границ внедрения и определение стратегии внедрения;
̶ определение общего графика проекта и последовательности внедрения;
̶ инициация подходящих для проекта стандартов и процедур;
̶ утверждение организации проекта и его управляющих органов;
̶ распределение ресурсов.
Обратив внимание на это заранее, перед внедрением, можно быть уверенным, что проект будет протекать рационально, в соответствии с заложенной крепкой основой для успешного внедрения SAP.
б) концептуальный проект;
Назначение фазы концептуального проектирования — это создание концептуального проекта, который является детализированным документом, содержащим результаты, полученные на протяжении процесса сбора требований. Кроме того, концептуальный проект документирует требования бизнес процессов компании. Вместе с этим, это способствует лучшему пониманию того, как компания намерена запустить свой бизнес внутри системы программного обеспечения SAP.
В течение этой фазы необходимо обратиться к следующему:
̶ учреждение управления организационными изменениями смягчения рисков, порождаемых организационными изменениями;
̶ уточнение изначальных целей проекта;
̶ определение основных границ предметной области;
̶ уточнение общего графика проекта и последовательности внедрения;
̶ уточнение технического проекта решения.
Необходимо особо отметить, что фаза оканчивается в разрезе всех областей знаний проекта внедрения созданием единого концептуального проекта, который по окончании фазы «замораживается» и в дальнейшем пересмотру не подлежит. В этом месте особенно ярко проявляется строгая каскадная модель, заложенная в основу ASAP.
в) реализация;
Назначение фазы реализации — реализовать в программном обеспечении требования бизнес процессов, основываясь на концептуальном проекте. Целью фазы являются окончательная реализация в системе, всеобщее тестирование и выпуск системы в качестве продукта. В дополнение, проектная команда получает соответствующие знания.
В течение этой фазы также выполняются следующие действия:
̶ совершенствуется управление организационными изменениями;
̶ определяется стратегия перехода на новую систему и передачи решения;
̶ настраиваются системные роли пользователей в масштабах всего предприятия и права доступа.
г) заключительная подготовка;
Назначение фазы заключительной подготовки — это завершение окончательной подготовки (включая системное тестирование, обучение конечных пользователей, управление системой и действия по передаче) к запуску продукта. Фаза заключительной подготовки также служит для разрешения всех открытых ключевых вопросов. При удачном завершении этой фазы бизнес может быть запущен в системе программного обеспечения SAP.
В течение этой фазы также выполняются следующие действия:
̶ достигается убежденность в надлежащих результатах управления организационными изменениями;
̶ достигается убежденность в том, что функциональная и техническая поддержки для продуктивной системы созданы.
д) поддержка и эксплуатация.
Назначение фазы эксплуатации и поддержки — это передача системы в продуктивную эксплуатацию и последующее сопровождение. Существуют два отдельных периода этой фазы:
̶ окончание проекта;
С течением времени, когда система будет выпущена, все проблемы будут разрешены, передача команде продуктивной поддержки будет закончена, передача знаний будет произведена, проект будет формально завершен.
̶ дальнейшее совершенствование.
Теперь, когда проект завершен, команда продуктивной поддержки осуществляет мониторинг системы и разрешает вновь возникшие проблемы, связанные с реализацией бизнес процессов в системе. Надлежащие процедуры управления изменениями установлены и произведено обучение конечных пользователей. Подготовлены планы постоянного пересмотра и совершенствования бизнес процессов.
В течение этой фазы также выполняются следующие действия:
̶ достигается окончательная приемка заказчиком;
̶ выполняется закрытие проекта.
Методология ASAP структурируется вокруг основных рабочих потоков проекта. Для каждого рабочего потока в методологии перечисляется ряд поставляемых результатов, которые должны быть подготовлены на каждой фазе проекта.
Кратко рассмотрим каждый из рабочих потоков, используя материалы самой дорожной карты:
а) управление проектом;
Подробное описание рабочего потока «Управление проектом» представлено на рисунке 4.
Рисунок 4 — Рабочий поток «Управление проектом»
Целью рабочего потока «Управление проектом» является предоставление требований для проекта внедрения SAP, выполнение и контроль проекта.
б) управление организационными изменениями
Подробное описание рабочего потока «Управление организационными изменениями» представлено на рисунке 5.
Рисунок 5 — Рабочий поток «Управление организационными изменениями»
Целью рабочего потока «Управление организационными изменениями» является поддержка ряда операций для внедрения SAP:
̶ запуск/настройка;
̶ управление стейкхолдерами;
̶ коммуникация;
̶ согласование организации;
̶ управление производительностью;
̶ мониторинг.
в) обучение;
Подробное описание рабочего потока «Обучение» представлено на рисунке 6.
Рисунок 6 — Рабочий поток «Обучение»
Целью рабочего потока «Обучение» является подготовка двух различных групп, задействованных при внедрении SAP: команда проекта и конечные пользователи.
г) управление данными;
Подробное описание рабочего потока «Управление данными» представлено на рисунке 7.
Рисунок 7 — Рабочий поток «Управление данными»
Целью рабочего потока «Управление данными» является поддержка двух основных операций управления данными для внедрения SAP: миграция и архивирование накопленных данных.
Накопленные данные можно классифицировать по трем видам:
̶ накопленные данные миграции – существующие данные, подлежащие миграции и доступные в SAP;
̶ накопленные данные архива – существующие данные, которые все еще требуются для исторической отчетности и анализа, но не должны содержаться в SAP;
̶ накопленные устаревшие данные – существующие данные, которые более не требуются для операционной деятельности и, таким образом, могут быть исключены из объема миграции.
д) управление бизнес-процессами;
Подробное описание рабочего потока «Управление бизнес-процессами» представлено на рисунке 8.
Рисунок 8 — Рабочий поток «Управление бизнес-процессами»
Целью рабочего потока «Управление бизнес-процессами» являются разработка процессов, поддерживающих модель бизнеса компаний и создание системного решения, включающего удобные приложения, которые устраняют обнаруженные узкие места, повышают эффективность, создают возможность инноваций и преимущества для предприятий клиента.
е) управление техническим решением;
Подробное описание рабочего потока «Управление техническим решением» представлено на рисунке 9.
Рисунок 9 — Рабочий поток «Управление техническим решением»
Целью рабочего потока «Управление техническим решением» является решение всех архитектурных и технических вопросов, связанных с проектом внедрения SAP.
Результаты рабочего потока «Управление техническим решением» должны обеспечить следующее:
̶ удовлетворение архитектурного и технического проектов ландшафта решения бизнес-требованиям из рабочего потока «Управление бизнес-процессами»;
̶ соблюдение технических требований, определенных при подготовке проекта;
̶ соблюдение нефункциональных требований, определенных при подготовке проекта, включая эксплуатационную пригодность, возможность поддержки, масштабируемость.
ж) управление интегрированными решением.
Подробное описание рабочего потока «Управление интегрированным решением» представлено на рисунке 10.
Рисунок 10 — Рабочий поток «Управление интегрированным решением»
Целью рабочего потока «Управление интегрированным решением» является выявление основных процессов, процедур и результатов тестирования решения, актуальных для проекта внедрения SAP.
В данном рабочем потоке выполняется организация тестирования отдельных процессов, шагов процессов и сценариев подготовки перехода к продуктивной эксплуатации решения SAP.
В исследовании будут рассмотрены все рабочие потоки и все фазы проекта для принятия решения об адаптации методологии.
1.4.2 Сильные и слабые стороны методологии
Как отмечалось ранее, в основе методологии ASAP лежит строгая каскадная модель. В связи с этим она наследует некоторые ее достоинства и некоторые ее недостатки [8].
В результате исследования были выявлены следующие преимущества:
а) каскадный подход хорошо известен клиентам, не имеющим отношения к разработке и эксплуатации программного обеспечения, и конечным пользователям;
б) методология доступна для понимания, так как преследуется простая цель — выполнить необходимые действия;
в) методология проста и удобна в применении, так как процесс разработки выполняется поэтапно;
г) структурой методологии может руководствоваться даже слабо подготовленный в техническом плане или неопытный персонал;
д) методология представляет собой шаблон, в который можно поместить методы для выполнения анализа, проектирования, кодирования, тестирования и т.д.;
е) методология способствует осуществлению строгого контроля менеджмента проекта;
ж) при правильном использовании методологии дефекты можно обнаружить на более ранних этапах, когда их устранение еще не требует относительно больших затрат;
з) методология определяет процедуры контроля качества посредством регулярных обзоров фаз;
и) ход выполнения проекта легко проследить с помощью использования временной шкалы (или диаграммы Ганта), поскольку момент завершения каждой фазы используется в качестве вехи.
В результате исследования были выявлены следующие недостатки:
а) в основе методологии лежит последовательная линейная структура, в результате чего каждая попытка вернуться на одну или две фазы назад, чтобы исправить какую-либо проблему или недостаток, приведет к нарушению методологии и значительному увеличению затрат на осуществление проекта и сбою в графике;
б) методология не отображает реально процесс разработки и внедрения программного обеспечения: отдельные фазы строго связаны с определенными действиями, что отличается от реальной работы коллектива разработчиков;
в) необнаруженные ранее ошибки или конструктивные недостатки в заключительной фазе проекта существенно повышают риски внедрения при остром дефиците времени и ресурсов на их устранение;
г) конечный пользователь практически не имеет возможности ознакомиться с системой заранее, лишь в самом конце проекта;
д) на практике конечный пользователь не участвует даже в сборе требований, он сталкивается с навязанной стандартной, часто не соответствующей действительным нуждам пользователя, функциональностью во время обучения в завершающей фазе;
е) клиент также не имеет возможности воспользоваться доступными промежуточными результатами, что практически исключает обратную связь пользователей с разработчиками по поводу отзывов о продукте;
ж) каждая фаза является предпосылкой для выполнения последующих действий, что является рискованным выбором для систем, не имеющих аналогов, а также новых модификаций существующих систем, это особенно актуально в нашей стране при внедрении ERP систем в нетрадиционных для ERP отраслях: пищевая промышленность, фармацевтическая промышленность, транспорт и т.д.;
з) для каждой фазы создаются данные (акселераторы), которые по завершении фазы считаются замороженными — они не должны изменяться на следующих этапах процесса разработки и внедрения программного обеспечения, что на практике встречается достаточно редко;
и) все требования к будущему продукту должны быть известны в начале процесса разработки и внедрения программного обеспечения, но клиенты редко могут исчерпывающе сформулировать все четко заданные требования на ранних фазах;
к) использование методологии может повлечь за собой значительные затраты, если требования в недостаточной мере известны или подвержены динамическим изменениям во время протекания процесса разработки и внедрения, что очень характерно для внедрения ERP систем на отечественных предприятиях;
л) необходимость в жестком управлении и контроле, поскольку в методологии почти не предусмотрена возможность модификации требований.
Таким образом, на самом верхнем уровне абстракции, методология ASAP содержит достаточно много белых пятен и не создает ощущения целостной системы из накопленных знаний, проверенных на протяжении многих лет в многочисленных практических внедрениях, и инструментов, предоставляемых для удобного применения этих знаний.
1.4.3 Использование методологии
Еще одной частью исследования методологии, является рассмотрение вопроса, в какой степени методология используется в реальных проектах. Изучение степени использования проводилось в проектном отделе фармацевтической компании, в котором данная методология сейчас используется.
Для этого были рассмотрены отдельные разделы методологии, каждый раздел был оценен отдельно, результаты оценки представлены в таблице 1. Оценка проводилась на основании существующей проектной документации и опроса проектной команды.
Таблица 1 – Степень использования разделов методологии ASAP
Раздел ASAP Используется полностью Используется большая часть Используется половина Используется меньшая часть Не используется совсем
Начальная подготовка
Концептуальный проект
Реализация
Заключительная подготовка
Эксплуатация и поддержка
По итогам исследования данного вопроса, получились результаты, представленные в таблице 1. Исходя из этих данных, можно сделать вывод, что в среднем на практике применяется половина описанной информации из различных разделов методологии, а в некоторых случаях и вовсе малая часть. На практике возникают ситуации, когда информации, представленной в методике, становится недостаточно или наоборот избыточно. В таких ситуациях, проектная команда испытывает трудности с быстрым и качественным определением требований заказчика.
Так же необходимо отметить, что на практике приходится часто сталкиваться с ситуацией, что в разных проектах тот или иной раздел методологии используется в разной степени, в зависимости от специфики проекта.
Фаза начальной подготовки является ключевой. Так как на основании полученных требований и строится дальнейшая работа проекта и в этом разделе, как уже было ранее отмечено, были выявлены ключевые риски. Важный момент — верно определить и оценить пожелания заказчика. Ведь, в противном случае, если недооценить сложность реализации требований, это может привести к провалу всего проекта.
При разработке адаптированной методологии необходимо отталкиваться от того, что вызывает в проектах центральные риски. Предотвращение этих рисков является залогом успеха проекта внедрения. Для этого был проведен тщательный анализ, состоящий в подробном исследовании рисков относительно фаз методологии ASAP c целью выявить ключевые рисковые моменты.
В результате анализа была составлена таблица, содержащая фазы методологии ASAP, и риски, относящиеся к рассматриваемой фазе и существующие на проектах по внедрению ИТ-систем, а также степень корреляции, которая показывает взаимосвязь между фазами и соответствующими рисками. Результаты представлены в таблице 2.
Оранжевым цветом выделены такие ячейки, в которых указанную степень корреляции между рисками и фазами методологии необходимо воплотить в жизнь. Зеленым цветом выделены такие ячейки, в которых степень корреляции между рисками и фазами методологии реально применяется на практике для реализации ИТ-проектов. Серым цветом выделены такие ячейки, в которых ожидания совпадают с реальностью относительно степени корреляции между рисками и фазами методологии.
Таблица 2 – Взаимосвязь между фазами методологии ASAP и рисками
Разделы Риски Оценка корреляции
Сильная Средняя Слабая Отсутствие
Подготовка проекта Неясные ожидания заказчика
Представители пользователей не доступны для встреч и проведения интервью
Стандарты и процедуры недостаточно определены или не полностью документированы
Стратегия преобразования недостаточно определена или не полностью документирована
Отсутствие стремления к изменению
Концептуальное проектирование Бизнес-стратегия организации и цели бизнес-процессов недостаточно определены
Слабо разработанные шаблоны документации
Неполноценное и несвязанное моделирование бизнес-процессов
Ограниченный доступ к информации о бизнес-направлениях
Точки интеграции со смежными приложениями недостаточно определены
Неполноценное взаимодействие консультантов и разработчиков
Реализация Неточные или неполные данные для настройки приложения
Неадекватное отражение бизнес-требований в тестовых сценариях
Некомпетентность проектной команды в преобразовании данных и настройке приложения
Недооценка времени для настройки и отладки приложения
Неполное отражение преобразованных данных вследствие нерешенных проблем с конфигурацией приложения или интеграцией со смежными приложениями
Заключительная подготовка Неполная или неготовая пользовательская документация
Невыполненные дополнительные разработки
Неготовая продуктивная версия для начала эксплуатации
Слабое управление организационными изменениями
1 2 3 4 5 6
Эксплуатация и поддержка Производительность приложения не поддерживает объем операций
Конечные пользователи не обладают достаточными знаниями приложения
Нежелание подписи акта приемки
Ненадлежащая функциональность приложения
В результате анализа, получилась наглядная картина того, в какой степени методологию применяют на реальных проектах. Из приведенных данных можно выделить следующие узкие места, которым было уделено недостаточное внимание:
̶ неясные ожидания заказчика;
̶ неполноценное и несвязанное моделирование бизнес-процессов;
̶ неточные или неполные данные для настройки приложения;
̶ неполное отражение преобразованных данных вследствие нерешенных проблем с конфигурацией приложения или интеграцией приложения со смежными приложениями;
̶ конечные пользователи не обладают достаточными знаниями приложения.
Можно сделать вывод о том, что недостаточное внимание уделяют вопросу, связанному с увязкой бизнес-требований и формулировкой общих требований к системе, в результате чего возникают существенные проблемы.
Выводы по 1 главе
Организационная и управленческая сложность проекта, а также требования системы обеспечения качества лекарственных средств GxP в фармацевтической отрасли определяют дополнительные требования к процессу внедрения информационных систем класса ERP и должны быть учтены при любом ИТ-проекте.
По результатам исследования предметной области было определено, в какой степени методологию ASAP применяют на реальном ИТ-проекте в фармацевтическом предприятии, а также определены узкие места данной методологии.
Таким образом, дальнейшее исследование будет направлено в сторону адаптации методологии ASAP для реализации ИТ-проектов в фармацевтической отрасли.
Список использованных источников
1. Круглов М.Г., Сергеев С.К, Такташов В.А., Фирстов В.Г., Шишков Г.М. Менеджмент систем качества: Учеб. Пособие / – М.: ИПК Издательство стандартов, 1997.
2. Халл Э., Джексон К., Дик Д. Разработка и управление требованиями. Практическое руководство пользователя. – М: Telelogic, 2 издание, 2005.
3. 7 ИТ-идей спасут фармацевтов // Русский регистр. – URL: (дата обращения: 14.11.2016)
4. Стандарты систем менеджмента качества // Русский регистр. – URL: (дата обращения: 27.11.2016)
5. Федотова А.Е. Основы GMP. – М: Асинком, 2012.
6. Пятигорская Н.В. Исследование и методологические подходы создания современных фармацевтических предприятий Российской Федерации. – Автореферат. – Москва, 2011.
7. ASA380. – Методология внедрения ASAP 7.1 в деталях. – SAP AG, 2010.
8. Вивек К. Внедрение SAP R/3: Руководство для менеджеров и инженеров. –
М.: АйТи, 2006.
9. GAMP 5. A risk-based approach to compliant GxP computerized systems. – ISPE, 2008.